home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group D. Borman, Editor
- Request for Comments: 1408 Cray Research, Inc.
- January 1993
-
-
- Telnet Environment Option
-
- Status of this Memo
-
- This RFC specifies an IAB standards track protocol for the Internet
- community, and requests discussion and suggestions for improvements.
- Please refer to the current edition of the "IAB Official Protocol
- Standards" for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
- Abstract
-
- This document specifies a mechanism for passing environment
- information between a telnet client and server. Use of this
- mechanism enables a telnet user to propagate configuration
- information to a remote host when connecting.
-
- 1. Command Names and Codes
-
- ENVIRON 36
- IS 0
- SEND 1
- INFO 2
-
- VAR 0
- VALUE 1
- ESC 2
- USERVAR 3
-
- 2. Command Meanings
-
-
- IAC WILL ENVIRON
-
- The sender of this command is willing to send environment
- variables.
-
- IAC WONT ENVIRON
-
- The sender of this command refuses to send environment variables.
-
-
-
-
-
-
- Telnet Working Group [Page 1]
-
- RFC 1408 Telnet Environment Option January 1993
-
-
- IAC DO ENVIRON
-
- The sender of this command is willing to receive environment
- variables.
-
- IAC DONT ENVIRON
-
- The sender of this command refuses to accept environment
- variables.
-
- IAC SB ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE
-
- The sender of this command requests that the remote side send its
- environment variables. The "type" may be either VAR or USERVAR,
- to indicate either well known or user variable names. Only the
- side that is DO ENVIRON may initiate a SEND command. If a list of
- variables is specified, then only those variables should be sent.
- If no list is specified, then the default environment, of both
- well known and user defined variables, should be sent. If one of
- the variables has no name, then all the variables of that type
- (well known or user defined) in the default environment should be
- sent.
-
- IAC SB ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
-
- The sender of this command is sending environment variables. This
- command is sent in response to a SEND request. Only the side that
- is WILL ENVIRON may send an IS command. The "type"/VALUE pairs
- must be returned in the same order as the SEND request specified
- them, and there must be a response for each "type ..." explicitly
- requested. The "type" will be VAR or USERVAR. Multiple
- environment variables may be sent. The characters following a
- "type" up to the next "type" or VALUE specify the variable name.
- The characters following a VALUE up to the next "type" specify the
- value of the variable. If a "type" is not followed by a VALUE
- (e.g., by another VAR, USERVAR, or IAC SE) then that variable is
- undefined. If a VALUE is immediately followed by a "type" or IAC,
- then the variable is defined, but has no value. If an IAC is
- contained between the IS and the IAC SE, it must be sent as IAC
- IAC. If a variable or a value contains a VAR, it must be sent as
- ESC VAR.
-
- If a variable or a value contains a USERVAR, it must be sent as
- ESC USERVAR. If a variable or a value contains a VALUE, it must
- be sent as ESC VALUE. If a variable or a value contains an ESC,
- it must be sent as ESC ESC.
-
-
-
-
-
- Telnet Working Group [Page 2]
-
- RFC 1408 Telnet Environment Option January 1993
-
-
- IAC SB ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
-
- The sender of this command is sending information about environment
- variables that have changed. It is identical to the IS command,
- except that the command is INFO instead of IS. Only the side that
- is WILL ENVIRON may send an INFO command. The INFO command is not
- to be used to send initial information; the SEND/IS sequence is to
- be used for that. The INFO command is to be used to propagate
- changes in environment variables, and may be spontaneously
- generated.
-
- 3. Default Specification
-
- The default specification for this option is
-
- WONT ENVIRON
- DONT ENVIRON
-
- meaning there will not be any exchange of environment information.
-
- 4. Motivation
-
- Many operating systems have startup information and environment
- variables that contain information that should be propagated to
- remote machines when Telnet connections are established. Rather than
- create a new Telnet option each time someone comes up with some new
- information that they need propagated through a Telnet session, but
- that the Telnet session itself doesn't really need to know about,
- this generic information option can be used.
-
- 5. Well Known Variables
-
- USER This variable is used to transmit the user or account
- name that the client wishes to log into on the remote
- system. The format of the value the USER variable is
- system dependent, as determined by the remote system.
-
- JOB This variable is used to transmit the job ID that the
- client wishes to use when logging into the remote system.
- The format of the value the JOB variable is system
- dependent, as determined by the remote system.
-
- ACCT This variable is used to transmit the account ID that the
- client wishes to use when logging into the remote system.
- The format of the value the ACCT variable is system
- dependent, as determined by the remote system.
-
-
-
-
-
- Telnet Working Group [Page 3]
-
- RFC 1408 Telnet Environment Option January 1993
-
-
- PRINTER This variable is used to identify the default location
- for printer output. Because there does not currently
- exist a standard way of naming a printer on a network,
- the format of this variable is currently undefined.
-
- SYSTEMTYPE This is used to transmit the type of operating system on
- the system that sends this variable. It value is
- identical to the value of the SYSTEM (SYST) command in
- FTP [2]. The format of the value shall have as its
- first word one of the system names listed in the
- current version of the Assigned Numbers document [3].
-
- DISPLAY This variable is used to transmit the X display location
- of the client. The format for the value of the DISPLAY
- variable is:
- <host>:<dispnum>[.<screennum>]
- This information is identical to the information passed
- using the Telnet X-DISPLAY-LOCATION option. If both the
- DISPLAY environment variable, and the
- X-DISPLAY-LOCATION option[4] are received, and they
- contain conflicting information, the most recently
- received information received should be used.
-
- Because it is impossible to anticipate all variables that users may
- wish to exchange, the USERVAR type is provided to allow users to
- transmit arbitrary variable/value pairs. The use of an additional
- type allows implementations to distinguish between values derived by
- the remote host software and values supplied by the user. Paranoid
- implementations will most likely treat both types with an equal level
- of distrust. The results of a name-space collision between a well-
- known and a user variable are implementation specific.
-
- 6. Implementation Rules
-
- WILL and DO are used only at the beginning of the connection to
- obtain and grant permission for future negotiations.
-
- Once the two hosts have exchanged a WILL and a DO, the sender of the
- DO ENVIRON is free to request that environment variables be sent.
- Only the sender of the DO may send requests (IAC SB ENVIRON SEND IAC
- SE) and only the sender of the WILL may transmit actual environment
- information (via the IAC SB ENVIRON IS ... IAC SE command). Though
- this option may be used at anytime throughout the life of the telnet
- connection, the exchange of environment information will usually
- happen at the startup of the connection. This is because many
- operating systems only have mechanisms for propagating environment
- information at process creation, so the information is needed before
- the user logs in. In this section, anything that is in quotes is
-
-
-
- Telnet Working Group [Page 4]
-
- RFC 1408 Telnet Environment Option January 1993
-
-
- shorthand for a string of ASCII values. For example, "joe" means the
- three octet sequence (in decimal) 106 111 101.
-
- The receiving host is not required to put all variables that it
- receives into the environment. For example, if the client should
- send across USERVAR "TERM" VALUE "xterm" as an environment variable,
- and the TERMINAL-TYPE [1] option has already been used to determine
- the terminal type, the server may safely ignore the TERM variable.
- Also, some startup information may be used in other ways; for
- example, the values for "USER", "ACCT" and "PROJ" values might be
- used to decide which account to log into, and might never be put into
- the users environment. In general, if the server has already
- determined the value of an environment variable by some more accurate
- means, or if it does not understand a variable name, it may ignore
- the value sent in the ENVIRON option. The server may also prefer to
- just put all unknown information into the users environment. This is
- the suggested method of implementation, because it allows the user
- the most flexibility.
-
- The following is an example of use of the option:
-
- Host1 Host2
- IAC DO ENVIRON
- IAC WILL ENVIRON
- [ Host1 is now free to request environment information ]
- IAC SB ENVIRON SEND VAR "USER"
- VAR "ACCT" VAR USERVAR IAC SE
- [ The server has now explicitly asked for the USER and ACCT
- variables, the default set of well known environment variables,
- and the default set of user defined variables. Note that the
- client includes the USER information twice; once because it was
- explicitly asked for, and once because it is part of the
- default environment. ]
- IAC SB ENVIRON IS VAR "USER"
- VALUE "joe" VAR "ACCT" VALUE
- "kernel" VAR "USER" VALUE "joe"
- VAR "DISPLAY" VALUE "foo:0.0"
- USERVAR "SHELL" VALUE "/bin/csh"
- IAC SE
-
- It is legal for a client to respond with an empty environment (no
- data between the IAC SB and IAC SE) when no well-defined or user
- variables are currently defined. For example:
-
- IAC SB ENVIRON IS IAC SE
-
-
-
-
-
-
- Telnet Working Group [Page 5]
-
- RFC 1408 Telnet Environment Option January 1993
-
-
- is a valid response to any of the following:
-
- IAC SB ENVIRON SEND IAC SE
- IAC SB ENVIRON SEND VAR IAC SE
- IAC SB ENVIRON SEND USERVAR IAC SE
- IAC SB ENVIRON SEND VAR USERVAR IAC SE
-
- (The last example is equivalent to the first...)
-
- It is expected that any implementation that supports the Telnet
- ENVIRON option will support all of this specification.
-
- 7. Security Concerns
-
- It is important for an implementor of the ENVIRON option to
- understand the interaction of setting options and the
- login/authentication process. Specifically careful analysis should be
- done to determine which variables are "safe" to set prior to having
- the client login. An example of a bad choice would be permitting a
- variable to be changed that allows an intruder to circumvent or
- compromise the login/authentication program itself.
-
- 8. References
-
- [1] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
- Software, Inc., February 1989.
-
- [2] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
- 9, RFC 959, USC/Information Sciences Institute, October 1985.
-
- [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
- USC/Information Sciences Institute, July 1992.
-
- [4] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie
- Mellon University, March 1989.
-
- Security Considerations
-
- Security issues are discussed in Section 7.
-
-
-
-
-
-
-
-
-
-
-
-
- Telnet Working Group [Page 6]
-
- RFC 1408 Telnet Environment Option January 1993
-
-
- Author's Address
-
- David A. Borman, Editor
- Cray Research, Inc.
- 655F Lone Oak Drive
- Eagan, MN 55123
-
- Phone: (612) 452-6650
- EMail: dab@CRAY.COM
-
- Mailing List: telnet-ietf@CRAY.COM
-
- Chair's Address
-
- The working group can be contacted via the current chair:
-
- Steve Alexander
- INTERACTIVE Systems Corporation
- 1901 North Naper Boulevard
- Naperville, IL 60563-8895
-
- Phone: (708) 505-9100 x256
- EMail: stevea@isc.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Telnet Working Group [Page 7]
-
-